home *** CD-ROM | disk | FTP | other *** search
/ Amiga Game-Power / Amiga Game-Power.iso / anwendungen / gw print / bcpl / bcpl.doc < prev    next >
Text File  |  1994-05-20  |  11KB  |  207 lines
  1.                               BCPL
  2. Author: Bill Kinnersley
  3. Date: Mar 12, 1988
  4. Mail: Physics Dept.
  5.       Montana State University
  6.       Bozeman, MT 59717
  7. BITNET: iphwk@mtsunix1
  8. INTERNET: iphwk%mtsunix1.bitnet@cunyvm.cuny.edu
  9. UUCP: ...psuvax1!mtsunix1.bitnet!iphwk
  10. TRIPOS
  11.         AmigaDOS is a port of the TRIPOS operating system developed at
  12. Cambridge University.  From the beginning, Unix and C were meant for
  13. each other. The same thing goes for BCPL and TRIPOS.
  14.  
  15.         On the one hand, TRIPOS was written in a high level language
  16. (BCPL) to provide easy portability from one hardware to another.  A
  17. TRIPOS port requires only the construction of a native kernel to provide
  18. process management and message passing--exactly the services handled on
  19. the Amiga by Exec.  On the other hand, BCPL requires extensive run-time
  20. support that TRIPOS is designed to offer.
  21.         In fact the coupling between system and application is even
  22. stronger in TRIPOS than in Unix.  A TRIPOS application program is like a
  23. subroutine of the operating system.  It requires shared access to system
  24. variables (the Global Vector) and resident system libraries.  As a result,
  25. BCPL programs tend to be smaller than C programs.
  26.         TRIPOS was never designed to run on mainframes, nor on single
  27. user micros.  From the beginning it was intended to run a network of
  28. workstations.   The target was a collection of small memory, small disk
  29. capacity machines in a network environment.  Multitasking and message
  30. passing are clearly an essential feature of such an environment.
  31. Presumably the hooks for networking are still present in AmigaDOS...
  32. BCPL
  33.  
  34.         BCPL itself is an ancestor of C and is actually a somewhat lower
  35. level language.  (A sample BCPL program is given in the ROM KernelManual,
  36. Appendix G.)  References to BCPL and TRIPOS are:
  37.         Richards, Martin, "TRIPOS--A Portable Operating System
  38.                 for Mini-computers",
  39.                 Software Practice and Experience, 9, 513-526 (1979)
  40.         Richards, Martin, "BCPL--the language and its compiler"
  41.                 Cambridge University Press, 1979
  42.                 ISBN 0-521-21965-5   QA76.73 B17 R5
  43.                 Emery, Glyn, "BCPL and C", Blackwell, 1986
  44.                 ISBN 0-632-01607-8   QA76.73 B38 E44
  45.         Moody, Ken, "A Coroutine Mechanism for BCPL",
  46.                 Software Practice and Experience, 10, 765 (1980)
  47. BPTRS
  48.           BCPL is a typeless language--every data item takes up the
  49. same amount of storage.  In the 68000 family, pointers are 32 bits.
  50. Hence Amiga TRIPOS is forced to store all data in 32 bit longwords.
  51. Unfortunately, 68000 memory is not longword addressable.  Assembly
  52. expressions like 10(A0,D1) calculate an effective address assuming
  53. that the offsets 10 and D1 are measured in bytes.  This leads to the
  54. need for a distinction between APTRs which are byte addresses, and
  55. BPTRs which are longword addresses.  BPTR = APTR/4, and BPTRs can only
  56. point to locations which are longword aligned.
  57.         (Strings are the only exception to the uniform size rule.  BCPL
  58. strings are packed, four characters to a longword.)
  59. MULTITASKING
  60.         The main AmigaDOS facility for multitasking is the CLI.  CLI's
  61. are kept in a fixed array, so there is a maximum number of CLI's allowed
  62. at any time.  Every BCPL program must be launched from its own CLI.
  63.         When a CLI executes a command, it loads the program with LoadSeg
  64. and calls it as a subroutine (not a coroutine as claimed by the AmigaDOS
  65. manual).  It does not create a separate process.  Thus the command
  66. inherits all of the CLI's existing environment: the Task, the Process,
  67. the Input and Output file handles, etc.  When the program returns, the
  68. CLI is there to take care of the cleanup chores.  CLI's may be created
  69. in two ways:
  70.         NewCLI creates an interactive CLI.  A new window is created,
  71. along with a new instance of the CON: device.  The default Input and
  72. Output file handles refer to this device.  Interactive CLI's are
  73. destroyed by EndCLI merely by pushing them into the background.  A
  74. background CLI with nothing to do automatically commits suicide.
  75.         RUN creates a CLI in the background that executes a given
  76. command and then terminates.  The Input handle is a fake one containing
  77. the command in its input buffer.  The Output handle is shared with
  78. that of the creator.
  79.         An AmigaDOS Process may spawn an unlimited number of children
  80. using CreateProc.  (This is what WorkBench does.)  A process created in
  81. this manner automatically starts execution at once, but typically its
  82. first few lines of code causes it wait at the Process DOSPort for a
  83. startup message.  It then continues execution and replies to the message
  84. when done.  This approach is necessary because someone else needs to do
  85. the unloading: either the parent, the WorkBench, or a CLI.
  86.         LoadWB creates a child process, WorkBench, but exits without
  87. waiting for a reply.  As a result WorkBench cannot terminate.
  88.  
  89. INITIAL ENVIRONMENT
  90.         Upon entry to any BCPL routine, the register contents are as
  91. follows:
  92.         d0 - amount of global area currently in use
  93.         d1-d4 - up to 4 parameters.  Further parameters can be passed on
  94.                 the stack (see below).
  95.         d5-d7 - unused
  96.         a0 - base of system address space - always 0.
  97.                 RAM addresses are computed as offsets from a0
  98.         a1 - base of the current BCPL stack frame
  99.         a2 - pointer to the BCPL Global Vector
  100.         a3 - return address of the caller
  101.         a4 - entry address
  102.         a5 - pointer to a "caller" service routine
  103.         a6 - pointer to a "returner" service routine
  104.         a7 - stack for temporaries
  105.         This register environment is available to any application
  106. program.  However if you're programming in C, the startup code supplied
  107. by your linker generally ignores the initial register contents and
  108. eventually they get overwritten.
  109. The parameters passed by the CLI to an application are:
  110.         d0 - length of command line
  111.         a0 - APTR to command line
  112. The command itself may be found in the CLI->cli_Command field.  Two items
  113. are available on the stack: pointers to the top and the bottom of the
  114. stack that was allocated.
  115. STACKS AND CALLS
  116.         The a7 stack is rarely used by AmigaDOS, except for interfacing
  117. calls to Exec which must be C-like.  Normal BCPL calls use the a1 stack.
  118. It is organized by frames of local variables, growing toward higher RAM
  119. addresses.
  120.         In C the caller pushes parameters on the stack in reverse order,
  121. then does the call.  The callee pushes its own locals on the stack as
  122. needed and restores the original stack pointer when done.  The caller
  123. then pops the parameters off.  More specifically, C uses the 68000 LINK
  124. and UNLK instructions to maintain a stack pointer (SP) and a frame
  125. pointer (FP).  Upon entry to a subroutine:
  126.  
  127.           SP--->Nth local
  128.                 ...
  129.                 1st local
  130.           FP--->old FP
  131.                 return address
  132.                 2nd param
  133.                 ...
  134.         In BCPL, parameters and locals are not pushed.  There is a frame
  135. pointer, a1, but no stack pointer.  Instead the compiler maintains a
  136. "current size".  The caller puts his parameters in d1-d4, his current
  137. size in d0, the subroutine address in a4, and then jsr's to (a5).
  138.         The (a5) entry routine increments a1 by d0.  It pops the return
  139. address off the a7 stack into a3, saves a1, a3, and a4 in locations just
  140. BELOW a1, saves d1-d4 just ABOVE a1 (all without changing a1), and then
  141. jumps to (a4).  Upon entry to a subroutine:
  142.                 old a1
  143.                 return address
  144.                 entry address
  145.           a1--->1st param
  146.                 2nd param
  147.                 ...
  148. (Note that BCPL frames grow toward higher memory instead of lower.)  The
  149. (a6) exit routine restores a1, a3, and a4, and jumps to (a3).
  150.         A BCPL routine must therefore preserve a0, a1, a2, a5, a6 and a7.
  151. Results are typically returned in d1 and/or a1.
  152.         For example, suppose your last global is at 100(a1).  You must
  153. call a subroutine with d0 = 110.  The (a5) routine will save registers
  154. in 104, 108, and 10c, and put the first four parameters at 110, 114, 118,
  155. and 11c.  The called routine (using the new a1) will find them at (a1),
  156. 4(a1), 8(a1), and c(a1).  If you want to pass a 5th parameter, you must
  157. put it ahead of time at 120(a1).  The called routine will find it at 10(a1).
  158.         BCPL variables are either global or local.  Global variables are
  159. located in the Global Vector and are visible to all modules.  They are
  160. referenced by an offset from a2.
  161.         In C, the linker combines the globals declared by various program
  162. modules and arranges them in the common area.  BCPL is not linked!  The
  163. BCPL programmer must handle these details himself, declaring explicitly
  164. where each global is to be located in the Global Vector.
  165.         Blocks may be nested, but locals declared in surrounding blocks
  166. are not visible, i.e. nonlocal variables may not be referenced.
  167. SEGMENTS
  168.         A program exists on the disk in sections called hunks.  When the
  169. program is loaded, the hunks are separately relocated as segments, and
  170. these are linked together with headers to form a SegList.  Process
  171. creation combines the program's SegList with several system SegLists to
  172. make up a SegArray.  Execution begins at the beginning of the first
  173. SegList, which is system startup code.  Entries in the SegArray are
  174. allowed to be missing (0), and that is probably the reason for using
  175. an array: to allow easy addition and deletion of chunks of code.
  176.         For example, if a program is launched from the CLI, the SegArray
  177. looks like (4/sys1/sys2/sys3/0/prog).  If the program is RUN, theSegArray
  178. will be (4/sys1/sys2/0/sys4/prog).  If the program is CreateProc'ed, the
  179. array is only (2/sys1/sys2).
  180. MODULE STRUCTURE
  181. A BCPL module has the following structure:
  182.         dc.l    size    ;module size in longwords
  183.         dc.w    0       ;pad
  184.         dc.b    '09'    ;version
  185.         dc.b    name    ;name of the module as a BSTR
  186.         Any number of BCPL subroutines
  187.         ...
  188.         Table of Global definitions
  189.         dc.l    maxGV   ;GV size the module will need.
  190.         Each subroutine may be preceded by a BSTR label.  The main entry
  191. is always labeled "start  ".  If the subroutine uses local constants such
  192. as strings, these immediately follow the code.
  193.         The definition table is used to place public entry points into
  194. the GV.  This is done by the startup code, specifically the library
  195. function installseg().  The table consists of pairs:
  196.         (offset into the module in bytes, offset into the GV in longwords).
  197. The table runs in reverse order, and is terminated with a 0.  For example,
  198. if the module ends with
  199.         dc.l    0, 1,24, 85,504, 88
  200. it means there are two entries to be installed: offset 24 at GV:1 and
  201. offset 504 at GV:85.  The last number, 88, is the GV size requested.
  202.         All BCPL programs that can be called from the command line are
  203. composed of two hunks.  The first hunk is common startup code that makes
  204. a private copy of the system GV before installing the program's globals.
  205. The purpose is to insure that AmigaDOS commands are reentrant.  Global
  206. variables installed by one instance will not overwrite those of another.
  207.